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REMARKS 

L Overview 

These remarks are set forth in response to the Non-Final Office Action mailed 
September 24, 2007. As this amendment has been timely filed within the six-month 
statutory period, but in the first month subsequent to the three-month shortened statutory 
period, a one-month petition for extension of time and corresponding fee is filed 
herewith. Presently, claims 1 through 16 are pending in the Patent Application. Claims 
1,6, 11 and 14 are independent in nature. In the Non-Final Office Action, each of claims 
1-10 have been rejected under 35 U.S.C. § 101. Additionally, claims 1 through 16 have 
been rejected under 35 U.S.C. § 1 12, second paragraph. Yet further, claims 1-2, 5-7 and 
10 have been rejected under 35 U.S.C. § 102(b) as being unpatentable over U.S. Patent 
No. 6,507,812 to Meade. Finally, claims 3-4, 8-9 and 1 1-16 have been rejected under 35 
U.S.C. § 103(a) as being unpatentable over Meade. 

In response, Applicant has amended claims 1, 2, 5, 6, 7, 10, 1 1 and 14. Claims 1, 

6, 1 1 and 15 have been amended to provide that the multi-byte equivalents are wide Latin 

equivalents. Support for this amendment can be found in paragraph [001 1] of Applicant's 

specification in which it is stated: 

Notably, the multi-byte equivalent can be a wide Latin equivalent. A Latin equivalent, by 
way of example, can include the Unicode characters ranging from U+FF21 through 
U+FF5A. 

Claims 2 and 7 have been amended to more narrowly recite that the wide Latin 
equivalents can include Unicode characters ranging from U+FF21 through U+FF5A. 
Finally, Claims 5 and 10 have been amended merely to depend upon Claims 1 and 6, 
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respectively. Accordingly, Applicant's amendments have not introduced new matter into 
the specification. 

II. The Applicant's Invention 

The Applicants have invented a system, method and apparatus for testing multi- 
byte data handling in an application under test. In the invention, a source string of test 
data can be converted to a multi-byte string by converting each character in the string to 
its multi-byte equivalent. Once converted, the multi-byte equivalent version of the source 
string can be provided as input to an application under test to ensure that not only 
whether the user interface of the application test can properly render the multi-byte 
equivalent version of the source string, but also whether the internal logic of the 
application under test can process, store and retrieve the multi-byte representation of the 
source string. 

III. Rejections Under 35 U.S.C. § 101 

On page 2 of the Non-Final Office Action, the Examiner asserted that the claimed 
invention, as recited in claims 1 through 10, are directed to non-statutory subject matter. 
This rejection is respectfully traversed. In State Street Bank and Trust Company v. 
Signature Financial Group, Inc., 149 F.3d 1368, 47 USPQ2d 1596 (Fed Cir. 1998), the 
court set forth the criteria for establishing statutory subject matter under 35 U.S.C. § 101 
as follows: 

The question of whether a claim encompasses statutory subject matter should not focus 
on which of the four categories of subject matter a claim is directed to — process, 
machine, manufacture, or composition of matter — but rather on the essential 
characteristics of the subject matter, in particular, its practical utility. Section 101 
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specifies that statutory subject matter must also satisfy the other "conditions and 
requirements" of Title 35, including novelty, nonobviousness, and adequacy of disclosure 
and notice. See In re Warmerdam, 33 F.3d 1354, 1359, 31 USPQ2d 1754, 1757-58 (Fed. 
Cir. 1994). For purpose of our analysis, as noted above, claim 1 is directed to a machine 
programmed with the Hub and Spoke software and admittedly produces a "useful, 
concrete, and tangible result." Alappat, 33 F.3d at 1544, 31 USPQ2d at 1557. This 
renders it statutory subject matter, even if the useful result is expressed in numbers, such 
as price, profit, percentage, cost, or loss. 

Thus, as articulated above, the test for determining whether subject matter is patentable 

under 35 U.S. C. § 101 involves deciding if the subject matter produces a "useful, 

concrete, and tangible result." 

A discussion of the procedural considerations regarding a rejection based upon 

lack of utility (i.e., 35 U.S.C. § 101) is found in M.P.E.P. § 2107.02. Specifically, 

M.P.E.P. § 2107.02(1) states that: 

regardless of the category of invention that is claimed (e.g., product or process), an 
applicant need only make one credible assertion of specific utility for the claimed 
invention to satisfy 35 U.S.C. 101 and 35 U.S.C. 1 12 

In paragraph [0017] of Applicants' disclosure, it is stated that in the invention as claimed 

in claims 1,6, 11 and 16, 

[Ojnce converted, the multi-byte equivalent version of the source string can be provided 
as input to an application under test to ensure that not only whether the user interface of 
the application test can properly render the multi-byte equivalent version of the source 
string, but also whether the internal logic of the application under test can process, store 
and retrieve the multi-byte representation of the source string. 

The Applicant, therefore, has asserted a credible utility. As noted in M.P.E.P. § 

2107.02(III)(A), the Court of Customs and Patent Appeals in In re hanger stated the 

following: 

As a matter of Patent Office practice, a specification which contains a disclosure of utility 
which corresponds in scope to the subject matter sought to be patented must be taken as 
sufficient to satisfy the utility requirement of § 101 for the entire claimed subject matter 
unless there is a reason for one skilled in the art to question the objective truth of the 
statement of utility or its scope, (emphasis in original) 
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Since a credible utility is contained in Applicants' specification and expressed clearly and 
expressly in claims 1,6, 11, and 16, the utility requirement of 35 U.S.C. § 101 (i.e., 
whether the invention produces a useful, concrete, and tangible result) has been met. 
Therefore, Applicants respectfully solicit withdrawal of the imposed rejection of claims 
1-10 under 35 U.S.C. § 101. 



IV. Rejections Under 35 U.S.C. $ 1 12. Second Paragraphia) 

On page 3 of the non-final office action, the Examiner has rejected each of claims 
1 through 16 for indefiniteness. Specifically, the Examiner appears to be confused as to: 

i. how a single byte to multi byte conversion is performed; 

ii. how adding a fixed integer to a character is done; and, 

iii. how adding a base value into a character is done. 

At the outset, the Applicant notes that a complete and thorough teaching to all of these 
issues are provided in the Applicant's specification, paragraph [0019] in which it is stated 
with emphasis: 

[0019] FIG. 2 is a flow chart illustrating a process for testing multi-byte data handling in 
the system of FIG. 1. Beginning in block 210, a result string can be initialized and in 
block 220, a source string can be loaded for processing. In block 230, a first character in 
the source string can be loaded. If in decision block 240, the character is within a code 
range indicating that the character is alphanumeric in nature, whether upper or lower 
case, then the character can be widened from a single byte value to the multi-byte value 
in block 250. For example, a base code value can be added to the code value of the 
character to change the character type from a single byte native text value to its full 
width Latin equivalent. In the case of Unicode, for instance, the native text string 
"ABC" can convert to full width Latin by adding the integer value 65,248 to each of the 
letters "A", "B" and "C". 

This it should be plainly clear to the Examiner that characters are represented in a 

computing system by a code that can be manipulated arithmetically. Yet further, the 

Examiner implicitly concedes that converting characters from single byte native text to 
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double bytes is known to the skilled artisan by expressly referring to Meade, column 8, 

lines 23 through 26 where such a conversion is taught. 

Applicant refers the Examiner to M.P.E.P. 2164.01 in which it is stated: 

Any analysis of whether a particular claim is supported by the disclosure in an 
application requires a determination of whether that disclosure, when filed, contained 
sufficient information regarding the subject matter of the claims as to enable one skilled 
in the pertinent art to make and use the claimed invention. 

Surely, the Examiner would agree based upon the Examiner's understanding of Meade 

that one skilled in the pertinent art of the internationalization of computer software would 

understand the most basic aspects of character manipulation. The Examiner is further 

reminded that under M.P.E.P. 2164.01(a), the Examiner must conduct an analysis in 

considering at least eight factors to determine whether or not there is sufficient evidence 

to support a determination that a disclosure does not satisfy the enablement requirement. 

Specifically, as set forth in M.P.E.P. 2164.01(a), 

There are many factors to be considered when determining whether there is sufficient 
evidence to support a determination that a disclosure does not satisfy the enablement 
requirement and whether any necessary experimentation is "undue." These factors 
include, but are not limited to: 

(A) The breadth of the claims; 

(B) The nature of the invention; 

(C) The state of the prior art; 

(D) The level of one of ordinary skill; 

(E) The level of predictability in the art; 

(F) The amount of direction provided by the inventor; 

(G) The existence of working examples; and 

(H) The quantity of experimentation needed to make or use the invention based on the 
content of the disclosure. 



Importantly, "It is improper to conclude that a disclosure is not enabling based 
on an analysis of only one of the above factors while ignoring one or more of the others. 
The examiner's analysis must consider all the evidence related to each of these factors, 
and any conclusion of nonenablement must be based on the evidence as a whole. In re 
Wands , 858 F.2d 731, 740 (Fed. Cir. 1988). Accordingly, the Examiner must provide a 
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detailed account of Examiner's analysis that substantially comports with M.P.E.P. 
2164.01(a), or the Examiner must withdraw the rejections under 35 U.S.C. § 1 12, second 
paragraph. 

V. Rejections Under 35 U.S.C. $ 102(b) and 103(a) 

A. Characterization of Maede 

Meade relates to a mock translation method and system that converts base- 
language data and performs a mock translation on it to produce internationalization test 
data. In Meade, the mock translation data is created by inserting additional characters, 
such as a tilde into each of the text strings from the user interface of a software program. 
The additional characters are used as a placeholder to accommodate the additional space 
needed for later translating the text into a different language. In addition, field boundary 
characters, such as brackets, are used to designate the beginning and end of the text with 
the placeholders. This data is stored in localization files and displayed in a software 
application in place of the English or foreign-language text. Thus, by visually inspecting 
each screen, the programmer or proofreader is able to easily recognize many 
internationalization errors, without requiring the ability to read any foreign language. 

B. Traversal of the Rejections on the Art 

Applicant's amended independent claim 1 (and claim 6 by extension) recites as 
follows: 

1 . A method for testing multi-byte data handling comprising the steps of: 

converting each single byte native text character of a source string to a multi- 
byte equivalent comprising a wide Latin equivalent to produce a multi-byte test string; 
and, 
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providing said multi-byte test string to a testing tool for use when testing a 
computer program. 



The Examiner has stated that column 7, lines 8 through 9 and column 8, lines 23 through 

29 of Meade teach the conversion of "each single byte native text character of a source 

string to a multi-byte equivalent to produce a multi-byte test string" as expressly required 

by Applicant's claims 1 and 6. Indeed, column 8, lines 23 through 29 recite 

Each entry in the file is then mock translated by converting each single-byte character to 
its double-byte, double-width equivalent (step 810). Finally, the translated entries are 
written back to the localization files (step 720). Now, when the software application is 
run for testing, the mock- translated, double-wide text will appear in place of the original 
text. 

In rejecting claims 2 and 7 the Examiner further relies upon column 2, lines 61 

through 62 and column 8, lines 23 through 29 of Meade to address the limitation "wide 

Latin equivalent". Column 2, lines 61 through 62 state in its entirety, 

enclosed with brackets, i.e., [ ]. This mock translation data is stored in localization files 
and displayed in a software. 

Likewise, column 8, lines 23 through 29 state it its entirety, 

the localization files (step 800). Each entry in the file is then mock translated by 
converting each single-byte character to its double-byte, double-width equivalent (step 
810). Finally, the translated entries are written back to the localization files (step 720). 
Now, when the software application is run for testing, the mock-translated, double-wide 
text will appear in place of the original text. 

Obviously, there is no mention of "wide Latin equivalent" or any such synonymous term. 

In as all of the amended independent claims require a "wide Latin equivalent", the 

Examiner must either find an express recitation to a "wide Latin equivalent" or the 

Examiner must withdraw the rejection. 
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VI. Conclusion 

The Applicants respectfully request the withdrawal of the rejections under 35 
U.S.C. §§ 101, 1 12, second paragraph, 102(b) and 103(a) owing to the amended and 
cancelled claims and the foregoing remarks. The Applicants request that the Examiner 
call the undersigned if clarification is needed on any matter within this Amendment, or if 
the Examiner believes a telephone interview would expedite the prosecution of the 
subject application to completion. 

Respectfully submitted, 



Date: December 27, 2007 /Steven M. Greenberg/ 

Steven M. Greenberg, Reg. No.: 44,725 

Attorney for Applicant(s) 

Carey, Rodriguez, Greenberg & Paul, LLP 

950 Peninsula Corporate Circle, Suite 3020 

Boca Raton, Florida 33487 

Customer No. 46321 

Tel: (561)922-3845 

Fax: (561)244-1062 
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